The development during the last decade or during the last years has made it possible for users to access many different types of services in different manners. Services are available over fixed as well as wireless networks and there is a large variety of services such as speech, data services, video services, media services etc. Access to the increasing number of services can be provided using different access technologies e.g. via PSTN (Public Switched Telecommunications Network), via mobile communication networks, television channels or via cable or satellite, over Internet provided over PSTN or broadband, and over wireless access networks, for example WLANs (Wireless Local Area Network). For wireless user stations services can be accessed in many different ways.
The requirements are different for different types of services. Therefore the Quality of Service (QoS) concept has been introduced.
3G mobile networks (3GPP, Third Generation Partnership Project) support four different types of radio access bearers for the communication links. These radio access bearers (RABs) are of types; conversational, streaming, interactive and background and they differ in the supported quality of service (QoS).
For a conversational RAB the requirements are stringent and it is important that there is a low delay and preservation of time relation (variation) between information entities of the traffic stream. A typical example of a conversational application is speech.
A streaming RAB is required to preserve the time relation in the same manner as a conversational RAB but it does not guarantee a low delay. A typical example is streaming video.
An interactive RAB is suitable for applications such as web browsing since it is merely used for applications following a request-response pattern. This is a best effort RAB. Finally, a background RAB can be used for applications when data is not expected within a certain time frame. Examples of applications for which a background RAB is appropriate are e-mails and background downloads etc. The background RAB is also a best effort RAB.
The behaviour of the RABs discussed above is designed for, and suitable for human-to-human communication, when an RAB is needed continuously as long as conversation is ongoing, or for human-to-computer communication, e.g. web browsing (an RAB can go to inactive state while waiting for certain buffers to fill up).
It is however estimated that in the near future there will be hundreds of millions of mobile connections and that more than fifty percent of these connections will be machine or other non-human originated connections. In fact, such non-human originated connections will have an entirely different traffic pattern than the majority of connections of today which have a human origin. It is believed that monitoring networks such as sensor networks monitoring industrial processes will be required to forward measurement data to operators or to a central database or somewhere else more or less periodically.
One way to handle such transfer events is to set up a new communication link or an RAB for each transfer event. However, it should be borne in mind that often the amount of data sent during each transfer event will be very small, in some applications for example only a couple of bits. This means that the establishment and release of an RAB for that purpose only involves an un-proportionally high use of signalling data in relation to the actual user data transferred each time, i.e. establishment and release of an RAB each time involves a significant signalling overhead. This means, inherently, that the utilization of network resources will be very poor. Frequent establishment and release of communication links also negatively affects the machine generating the information to be transferred. This is particularly so in the case of sensor networks which often have limited energy resources and therefore the lifetime of such machines will be and for example energy storages will have to be replaced.
Another way to handle such events could be to establish an RAB and keep it indefinitely. However, in that case network resources are also unnecessarily occupied when there is no data or no information to be sent, and only very small amounts are sent each time. This reduces the overall network capacity and it is a waste of signalling as well as traffic resources, which also reduces the ability and capacity to support other services and users.
It has been established that if an interactive RAB is set up for handling repetitive transfer of information, it could be configured in such a way that it goes to an inactive state (sleep mode) when there is no information or data to transfer. Then most of the network resources are released and they could be made to “wake up” again when a designated buffer is filled up. However, there is no way to guarantee access to network resources every time that a transfer event to be carried out. This means that once a buffer is filled up and data should be transferred, network resources have to be allocated again. Then it is not certain that network resources actually are available since in the meantime they may have been occupied by other users. In general, network resources are allocated on a first come—first served basis and there is no possibility to take into account any repetitive transfer pattern.
A conversational RAB can not be put into a passive, sleep state. It is either fully active and network resources allocated, or it does not exist. This is applicable also for a streaming RAB.
It is also not satisfactory to use a background RAB since no timely delivery of information can be guaranteed which, is often important e.g. in process control monitoring data, medical data transfer etc.
Thus, today there is no satisfactory way of handling transfer of information, particularly of comparably small amounts of data, occurring more or less regularly, or following a repetitive transfer pattern.